home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / Re Using Counted Ptr objects an < prev    next >
Encoding:
Internet Message Format  |  1996-07-15  |  4.5 KB  |  [TEXT/ttxt]
  1. Subject:     Re:Using Counted Ptr objects and Collections?
  2. Sent:        7/15/96 8:32 AM
  3. Received:    7/15/96 8:39 AM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Itrat Khan wrote:
  9.  
  10. > I'm using an object that I wish to be both reference-counted (pointer
  11. > based using FW_TCountedPtr) and part of an ordered collection
  12. > (FW_TOrderedCollection). Here are the problems I run into (pretend my
  13. > object's type is called CMyClass):
  14.  
  15. There is precedent for this sort of thing in ODF. Take a look at
  16. FW_CScriptableCollection in the Semantic Events subsystem of the Framework
  17. layer. FW_CScriptableCollection collects instances of FW_MScriptable.
  18. FW_MScriptable is can optionally be reference counted. FW_MScriptables are
  19. acquired and released through calls to FW_MScriptable::AcquireScriptable
  20. and FW_MScriptable::ReleaseScriptable respectively. By default, these
  21. methods do nothing, since FW_MScriptable will often be mixed into classes
  22. that are not reference counted. FW_CPropertyDesignator is an example of a
  23. subclass of FW_MScriptable that implements these methods to provide
  24. reference counted behavior.
  25.  
  26. This approach requires consideration of the aspect of reference counted
  27. objects that suggests that, by definition, reference counted objects are
  28. not "owned" by other objects - they own themselves. What are the
  29. implications of adding these object to collections, then?  Shouldn't it be
  30. true, then, that if an object is added to a collection, the collection
  31. should acquire the object? Shouldn't it be true that the collection should
  32. release the object when it's removed from the collection? What if the
  33. collection is destroyed? FW_CScriptableCollection implements these
  34. behaviors appropriately. It also provides only limited access to collection
  35. operators, since I wanted to impose some specific design constraints.
  36.  
  37. I suggest you carefully consider these issues before you decide to go ahead
  38. with the pattern you are considering. There is nothing wrong with it, but
  39. you might want to consider all of the implications before deciding to go
  40. ahead with it.
  41.  
  42. > * FW_TOrderedCollection methods such as AddFirst() require me to
  43. > provide a pointer to an object such as (CMyClass* element).
  44. >
  45. > * The overloaded -> operator for FW_TCountedPtr won't work with a
  46. > pointer to an object. The object has to be declared as (CMyClass
  47. > element).
  48.  
  49. Remember that reference counting is comprised of two components: a
  50. representation object that owns a reference count, and a pointer class that
  51. knows how to incremement and decrement the reference count of
  52. representation objects (usually via calls to representation methods such as
  53. Acquire and Release).
  54.  
  55. I think you may be confusing the two. You should mix FW_MCountedPtrRep into
  56. CMyClass. When you create your collection, make it a collection of
  57. CMyClass. You'll then create a second class, possible an instantiation of
  58. FW_TCountedPtr, that points at objects of CMyClass.
  59.  
  60. class CMyClass : public FW_MCountedPtrRep
  61. {
  62.     // words...words...words
  63. };
  64.  
  65. typedef FW_TCountedPtr<CMyClass> CMyClassPtr;
  66.  
  67.  
  68. > So I'd have to do something like this:
  69. >
  70. >     // ----- Add some arbitrary element to the front of the list. -----
  71. >     CMyClass*  element = new CMyClass();
  72. >     orderedCollection->AddFirst(element);
  73.  
  74.  
  75. The code above becomes:
  76.  
  77. CMyClassPtr ptr = new CMyClass;
  78. orderedCollection->AddFirst(ptr);
  79.  
  80. This works, because of the conversion operator in CMyClassPtr that converts
  81. ptr to a CMyClass*. As I mentioned earlier, you'll probably want the
  82. collection to acquire the class object when its added to the collection.
  83.  
  84. >     // ----- Later,  retrieve the element and work with it. -----
  85. >     element = orderedCollection->First();
  86. >     (*element)->GetInfoOrSomething();   // This is what gets messy.
  87.  
  88. becomes:
  89.  
  90. CMyClassPtr ptr = orderedCollection->First();
  91. ptr->GetInfoOrSomething();    // not messy at all
  92.  
  93.  
  94. > I know the first scenario works and I guess the second will too, I'm
  95. > just wondering if this is the only way I can use these subsystems
  96. > together or if there's a simpler way. I know this is a C++ question,
  97. > but can I overload the -> operator so it would work as follows:
  98. >
  99. >     CMyClass* element;
  100. >     element->GetInfoOrSomething();
  101. >
  102. > and behind the scenes it really translates the last line to:
  103. >
  104. >     element->fRep->GetInfoOrSomething();
  105.  
  106. The "member selection operator" is already overloaded in the FW_TCountedPtr
  107. template to do this.
  108.  
  109. Greg.
  110.  
  111.  
  112. _________________________________________________________
  113. Greg Friedman      ODF Engineering       Apple Computer
  114.  
  115.  
  116.